Just Forget It - The Semantics and Enforcement of Information Erasure

There are many settings in which sensitive information is made available to a system or organisation for a specific purpose, on the understanding that it will be erased once that purpose has been fulfilled. A familiar example is that of online credit card transactions: a customer typically provides credit card details to a payment system on the understanding that the following promises are kept: (i) Noninterference (NI): the card details may flow to the bank (in order that the payment can be authorised) but not to other users of the system; (ii) Erasure: the payment system will not retain any record of the card details once the transaction is complete. This example shows that we need to reason about NI and erasure in combination, and that we need to consider interactive systems: the card details are used in the interaction between the principals, and then erased; without the interaction, the card details could be dispensed with altogether and erasure would be unnecessary. The contributions of this paper are as follows. (i) We show that an end-to-end erasure property can be encoded as a “flow sensitive” noninterference property. (ii) By a judicious choice of language construct to support erasure policies, we successfully adapt this result to an interactive setting. (iii) We use this result to design a type system which guarantees that well typed programs are properly erasing. Although erasure policies have been discussed in earlier papers, this appears to be the first static analysis to enforce erasure. 1 Information Erasure There are many settings in which sensitive information is made available to a system or organisation for a specific purpose, on the understanding that it will be erased once that purpose has been fulfilled. Common examples involve erasure of some authentication token, such as voter identity in e-voting, or biometric data in fingerprint-activated left-luggage lockers. A more everyday example is an online credit card transaction. A customer typically provides credit card details to a payment system on the understanding that the following promises are kept: Noninterference (NI): the card details may flow to the bank (in order that the payement can be authorised) but not to other users of the system; Erasure: the payment system will not retain any record of the card details once the transaction is complete. In this case, erasure ensures that the transaction does not make the customer or bank vulnerable to breaches of security in the payment system which occur after the transaction is complete. Two aspects of erasure are illustrated by this example: To appear: Proceedings of ESOP’08, 17th European Symposium on Programming, Budapest, 29 March 6 April, 2008. Springer-Verlag (LNCS) 2 Hunt & Sands, ESOP’08 1. We need to be able to reason about NI and erasure in combination: we show that flow sensitive NI combined with erasure is equivalent to a re-classification of the erased input. 2. To give a satisfactory account of erasure, we need to consider interactive systems: the card details are used in the interaction between the customer, the payment system and the bank, and then erased; without the interaction, the card details could be dispensed with altogether and erasure would be unnecessary. Background The idea and motivations for studying erasure properties of programs come from recent work of Chong and Myers [CM05], and we borrow some notation from that paper. Their paper deals with expressive temporal information flow policies for program variables which include combinations of erasure and declassification. In their simplest form, erasure policies are written in the form a ↗ b, and are used to describe a variable whose security level is initially a, but which is erased to level b as soon as condition c (in principle an arbitrary property of the computation) is satisfied. Policies as described in [CM05] are quite complex (expressive), and their semantics is necessarily quite involved. It is perhaps not surprising that they have not described an enforcement mechanism (e.g. a type system) for their policy language. In this paper we take a fresh look at the erasure problem with a much less ambitious policy language. We focus on just erasure, independently from declassification concerns. We show how, together with a judicious choice of language construct to support erasure policies, we can take advantage of the close relationship between erasure semantics and noninterference to provide, to our knowledge, the first static analysis to enforce erasure policies. Summary We begin (Section 2) by considering what we call end-to-end erasure for non interactive programs. Consider the following trivial program: y := y+ 1 ; cc := 0. This program erases (the initial value of) cc. On the other hand, (if isVisa(cc) y := y + 1) ; cc := 0 does not erase cc, since some information about cc is retained by y. More generally (following [CM05]) we talk about erasure of a variable to a higher security level. In this very simple setting we show that: – an end-to-end erasure property can be encoded as a “flow sensitive” noninterference property (Proposition 1), and – if we also require that the program is noninterfering, then this is a necessary and sufficient condition for erasure (Proposition 2). while serverUp { input cc from user input details from user payment := process(cc) output payment to bank custInfo := custInfo ⊕ details cc := 0 } . . . End-to-end erasure is too simple to be useful in itself. In Section 3 we move on to the study of erasure in the presence of fresh inputs and program outputs. Consider for example the program to the right. Here the erasure property we might want is that no information about the input cc in the first line of the loop body can be observed after the transaction (the loop body) is complete. In this case the input is not erased because it is still present in payment , so if the